1. Field of the Invention
The present invention relates to security hardening of network devices, such as supervisory control and data acquisition (SCADA) field devices, against electronic intrusions (cyber-attacks). The present invention also relates to a device, method, and system for processing communications for secure operation of industrial control system field devices.
2. Background
A. Security Hardening of Network Devices
Network devices in computer networks, such as field devices employed in distributed control systems (DCSs), may connect devices and elements requiring protected operations, such as sensors and actuators, to control networks providing, for example, remote measuring and control capabilities. Field devices employed in DCSs will be used herein as an example of network devices requiring protected operations.
Early DCSs were isolated proprietary systems with limited exposure to cyber threats. For example, such DCSs often utilized dedicated serial communication lines and implemented proprietary communication protocols in connecting field devices to supervisory control and data acquisition (SCADA) system components. However, modern DCSs often engage commercial computing platforms and operating systems (e.g., Linux) and industry standard network technologies (e.g., Ethernet, TCP/IP), which significantly increase the vulnerability of the DCSs to cyber attacks.
While major disasters have thus far been averted, incidents such as the 2003 Slammer worm penetration of the Davis-Besse nuclear power plant network in Oak Harbor, Ohio, and the 2006 hacker attack on a water treatment facility in Harrisburg, Pa. underscore the significance of the cyber threat.
Field devices are attractive targets for cyber attacks on control systems. Since these devices are used for measurement and control of physical systems, preventing these attacks is essential to securing DCSs and, by extension, the critical infrastructures assets they operate. Unlike early field devices, which were highly specialized systems, modern field devices use commercially available hardware and software and can be attacked quite easily.
Thus, there is generally a need to secure network devices, such as field devices, and their operating systems.
In traditional IT communication structure, security is implemented by protecting servers (e.g., web servers), database “back ends,” etc., and the perimeter network devices are less protected (“hard protection in the middle, soft protection on the outside” security design). However, as discussed above, for SCADA networks there is a need to also protect perimeter network devices, such as the field devices in SCADA systems, which perform sensitive operations (similar to protecting the individual PCs in the traditional IT structure).
Efforts toward this end, to date, have included implementation of firewalls, and some work in adding security to communication protocols. SCADA protocols are implemented in the application layer of an IT device. However, for IT devices the operating system, and hardware, is the security enforcement base on which security in the application layer depends. The operating system itself, is a potential “attack surface.” Ultimately, any security layer above the operating system depends on the operating system to enforce that security.
With a monolithic kernel, which includes the operating system, drivers, and file system, if the operating system can be attacked, then security can be circumvented.
A microkernel is a kernel that contains only those elements that cannot be implemented outside the kernel. Instead of having an operating system that includes the functionality traditionally associated with most operating systems, such as Windows, only those functions that must be in the operating system remain therein. For example, Linux has approximately 15 million lines of code, and Windows has approximately 30 million lines of code. The OKL4, which is a microkernel, has only about 15,000 lines of code.
FIG. 1 is a schematic comparison of a monolithic kernel 10 to a microkernel 12.
Multiple independent levels of security (MILS) 14 (FIG. 2) and Nizza 16 (FIG. 3) are two microkernel-based security architectures. The MILS architecture, which was developed for high assurance and high performance computing, is based on Rushby's separation kernel (see: J. Liedtke, On micro-kernel construction, ACM SIGOPS Operating Systems Review, vol. 29(5), pp. 237-250, 1995). The MILS architecture enforces strict security and separation policies on data and processes within a single processor (see: A. Tanenbaum, J. Herder and H. Bos, Can we make operating systems reliable and secure? IEEE Computer, vol. 39(5), pp. 44-51, 2006). The Nizza architecture is based on the L4 microkernel and protects security critical code.
MILS and Nizza employ isolated partitions, each with its own protection domain, that allow software and data of different security levels or sensitivity to be decoupled from potentially less secure software. Secure compartmentalization of components and inter-process communication (IPC) allow the trusted computing base (TCB) to remain small, comprising only the kernel and security-critical code; application software resides outside the TCB. In the MILS architecture, this enables high assurance application layer reference monitors to be inserted between application software components. In Nizza, security-critical code is removed from commercial applications and placed in a protected isolated compartment, keeping the TCB small. An application of Nizza is to the secure signing of email (see: L. Singaravelu, C. Pu, H. Hartig and C. Helmuth, Reducing TCB complexity for security-sensitive applications: Three case studies, ACM SIGOPS Systems Review, vol. 40(4), pp. 161-174, 2006).
MILS and Nizza primarily focus on protecting the confidentiality of data. MILS is designed for government and military systems that have multilevel security (MLS) requirements, where independent systems have historically been used for different security levels. Nizza is aimed at desktop and commodity computing applications that require small TCBs, mainly for protecting sensitive user data.
However, availability and integrity—rather than confidentiality—are the principal goals in securing sensitive network devices themselves, such as field devices in SCADA systems. As such, MILS and Nizza do not provide the requisite functionality for securing such network devices.
B. Device, Method, and System for Processing Communications for Secure Operation of Industrial Control System Field Devices
Supervisory control and data acquisition (SCADA) and distributed control systems (DCS) are networks of computer based systems that provide remote telemetry of physical systems and processes. Collectively they are referred to as Industrial Control Systems (ICS). ICSs play a central role in the daily operation of a vast array of services and infrastructure on which we have all come to rely; these include: electric power, fresh drinking water, waste water treatment, gas and oil distribution, industrial manufacturing, and many others. A typical ICS system consists of: a Master (Master Telemetry Unit (MTU)/Human Machine Interface (HMI)), one or more field devices, and a communications infrastructure. The Master processes information received from field devices and sends control directives back out to field devices. Common types of field devices are remote telemetry units (RTU), intelligent electronic devices (IED) and programmable logic controllers (PLC). Field devices and the Master are connected by the communications infrastructure (i.e., a communications network). Many different medium are used for the communication network including: leased lines, PSTNs, cellular networks, and various types of UHF/VHF radio. In general the communication protocols used by field devices and Masters are referred to as SCADA protocols.
FIG. 8 shows the main elements of a simple SCADA system 400, including a Master 402, a field device 404, and a communication infrastructure 406.
When these systems were initially developed, little attention was paid to cyber-security because the systems were physically isolated and used proprietary hardware, software, and communication protocols. For many reasons such as: enterprise network connections to the control network, increased use of commodity hardware and software, and the increased use of TCP/IP in industrial communications networks, these systems are now vulnerable to cyber-based attacks. Legacy field devices present unique security challenges. Many legacy systems were designed before cyber-security concerns became relevant and so lack security features. Many also have reduced processing power, memory, and other storage resources, often to the degree that algorithms for cyber-security are not possible or practical to implement. Furthermore, these devices have long life-cycles, 20-30 years, and can be costly and difficult to replace.
One of the biggest continuing problems is unscrupulous persons finding a way to exploit something that was not planned. For example, an obscure combination of consecutive key strokes produces an unexpected result, resulting in a security breach in an otherwise secure and important piece of software.